home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 2 / Apprentice-Release2.iso / Tools / MPW / GCC 1.37.1r15 / Documents / Hacking GCC < prev    next >
Encoding:
Text File  |  1993-01-14  |  6.9 KB  |  136 lines  |  [TEXT/MPS ]
  1. FOLDERS AND PATHS
  2.  
  3. The script "BuildGCCStages" assumes that the main GCC folder is one level up from
  4. the folder it was in when executed.  If the script is anywhere else, then you will
  5. need to pass the path to that main folder as a second argument to BuildGCCStages.
  6. I recommend keeping all GCC stuff in a folder separate from MPW, but it's not required.
  7.  
  8. BISON
  9.  
  10. To rebuild GCC from scratch, you must first have Bison correctly installed.
  11.  
  12. [ptr to Bison versions]
  13.  
  14. REBUILDING
  15.  
  16. To do a basic recompilation, type "BuildGCCStages 1".  This will create a new folder
  17. GCC.MPW.s1, copy the necessary files from GCC.MPW, and create "first stage"
  18. (compiled by MPW C) tools, which can be put wherever you like.  The
  19. process takes 15-20 minutes on a IIci.  The results are not quite as good as when
  20. GCC compiles itself, but take a lot less time to produce and are fine for testing
  21. changes.
  22.  
  23. To get the best versions, you have to use GCC to compile itself.  Three complete
  24. compilations will be necessary, so do "BuildGCCStages 3".  On a IIci, it will run for
  25. about two hours.  If you say "BuildGCCStages 4" instead, then it will do one more
  26. self-compilation; the fourth-stage compiler should be *completely* identical to the
  27. third stage.  If not, then something is wrong.  In any case, the third stage cpp and
  28. cc1 (in GCC.MPW.s3) are the ones to use (drop them anywhere on your command path).
  29.  
  30. BuildGCCStages needs lots of extra diskspace, about 3Mb/stage over and above
  31. the 8Mb of the source distribution.  Actually, each stage only really needs
  32. the tools built in the previous stage, not the object or temp files, so they
  33. could be deleted to save space.
  34.  
  35. If I'm rebuilding for experimentation, I usually just add GCC.MPW to the front of
  36. my command path, to avoid the confusion of old versions getting used instead.  The
  37. -tools option is also useful for this.
  38.  
  39. Another speedup is to use the "insn" target instead of "cc1" if only the machine
  40. description "md" has been changed.  MPW makefiles have to do all the dependency
  41. checking before starting execution, which means that they can't take advantage of
  42. the fact that most of the insn-* files don't change when md is changed.  However,
  43. if you make "insn" and then "cc1", the makefile will only have to recompile the
  44. insn-* files that were actually changed by making "insn".
  45.  
  46. BUILDING GCC FOR 68000 and/or SANE
  47.  
  48. At present, one of GCC's unresolved bugs requires both -mc68020 and -mc68881 to be
  49. turned on when compiling itself.  GCC is too slow to be particularly attractive on
  50. older/slower Macs anyway, so this didn't seem like a real hardship. If you really
  51. really need a 68000+SANE GCC, but don't care about having it be self-compiled, you
  52. could build the first stage without -mc68020 and -mc68881 and use that; it is a little
  53. slower, and some optimizations are missing, but otherwise works fine.
  54.  
  55. TESTING
  56.  
  57. This is an important step.  The folder Tests has a few programs that are small
  58. enough to look at the assembly code, plus a version of dhrystone.  You should also
  59. try using gC to build the programs in the MPW CExamples folder.  Of course, when
  60. GCC successfully self-compiles, it is severely tested.  For test suites, we have
  61. used the "C Torture Test" (available on various Internet servers) and the commercial
  62. Plum-Hall test suite.
  63.  
  64. RETARGETING TO EXISTING MACHINES
  65.  
  66. To build GCC for other machines, create a folder GCC.<machine> and copy the desired
  67. machine-specific files from the Machines folder.  The copies will be something like
  68.  
  69.     copy :Machines:<machine>.md :GCC.<machine>:md
  70.     copy :Machines:tm-<machine>.h :GCC.<machine>:tm.h
  71.     copy :Machines:out-<machine>.c :GCC.<machine>:aux-output.c
  72.     copy :Machines:xm-<system>.h :GCC.<machine>:config.h
  73.  
  74. If you're working under MPW, then xm-mpw.h is almost always the correct file for
  75. config.h.  However, you should examine the file to be sure (for instance, if you
  76. don't want to support Apple's C dialect as the source language, then APPLE_C should
  77. be undefined).
  78.  
  79. The makefile should be identical to that used by MPW GCC, although you may want to
  80. change the programs' names from "cpp" and "cc1" to something else.  (Yes, cpp
  81. is slightly different for different target machines; for one thing, it has a different
  82. set of predefined symbols.)  The scripts gC and gCPlus invoking the compiler
  83. will also need to be changed as appropriate.  (Giving them different names is a good
  84. idea here too.)
  85.  
  86. RETARGETING TO NEW MACHINES
  87.  
  88. The first thing to do is to study both the GCC manual where it describes how to
  89. retarget, as well as existing machine descriptions, particularly for those machines
  90. with which you are familiar.  Unfortunately, there is no really crystal-clear
  91. description of retargeting anywhere.
  92.  
  93. The easiest approach is to find an existing machine description that is closest
  94. to the one you're interested, build the compiler so you know it will compile and
  95. run correctly, then gradually mutate the description until you're generating code
  96. for your machine.  Many of the more mysterious macros in tm.h are extremely
  97. difficult to write correctly, and if too many are changed all at once, it becomes
  98. well-nigh impossible to discover the cause of a compiler abort.
  99.  
  100. GCC INTERNALS
  101.  
  102. GCC is unusually well-written and well-documented, especially considering the size
  103. and complexity of its intended task.  Nearly all of the machine-independent code
  104. really is machine-independent, although its effectiveness falls off as one gets
  105. further away from the VAX/68K/88K/Mips spectrum of machines and the Unix/Unix-lookalike
  106. spectrum of operating systems.
  107.  
  108. The modifications that were made to get GCC to work under MPW fall into several
  109. categories, each flagged by a distinct preprocessor symbol.
  110.  
  111. MPW is for those changes required by the MPW environment, independent of the compiler
  112. used (typically #includes and file handling).  Most of these occur in contexts where
  113. you'll also see USG (System V Unix), VMS, and MSDOS conditionals.  There are some
  114. MPW_31 conditionals that are imagined (ahem) to work around bugs in MPW 3.1 only.
  115.  
  116. APPLE_C indicates those changes necessary to support Apple's dialect of C, such as
  117. the pascal keyword and direct function definitions.  However, some changes to the
  118. parser have not been so marked (since it gets run through bison).
  119.  
  120. MPW_C is for places in the GCC code that had to be changed to get the MPW C compiler
  121. to handle them correctly.  Some of these are MPW_C31, for bugs that are supposed to
  122. have been fixed in 3.2.
  123.  
  124. APPLE_HAX is for generic changes that would be worthwhile for any version of GCC.
  125. Some of these remove GCC's limitations with respect to the MPW environment, such as
  126. the need to import variables for each function, and work in conjunction with
  127. bits of the target machine description.
  128.  
  129. TROUBLESHOOTING
  130.  
  131. There are two routines crucial to debugging - debug_dump_tree() is a one-argument
  132. function that takes a tree structure and prints it on stderr, while debug_rtx()
  133. does the same for rtl expressions.  These are especially useful to insert just
  134. in front of a call to abort().
  135.  
  136.